Method of retrieving information from a notifying node of SIP/IMS network to a watcher client

ABSTRACT

A method of delivering information from a Notifying node of a SIP/IMS network to a Watcher Client, via an intermediate Watcher Proxy. A connection is established between the Watcher Proxy and the Watcher Client, using a SIP session, wherein the established connection is used for forwarding a request for a SIP subscription to the Watcher Proxy as an embedded SIP subscribe message. Once a backend SIP subscription has been setup between the Watcher Proxy and the Notifying node, SIP notify messages delivered from the Notifying node will be forwarded from the Watcher Proxy to the Watcher Client via the established connection, thereby separating SIP subscribe traffic from SIP control traffic.

This application claims the benefit of U.S. Provisional ApplicationNo.60/988,604, filed Nov. 16, 2007, the disclosure of which is fullyincorporated herein by reference.

TECHNICAL FIELD

The present invention generally relates to a method of deliveringnotifications according to a SIP event package event package, such ase.g. presentity information or XCAP changes, in an IMS network, and morespecifically to a method for avoiding interference between this type oftraffic and normal SIP traffic control signaling. The present inventionalso relates to a client and a node adapted to execute the method.

BACKGROUND

The IP Multimedia Subsystem (IMS) is an architecture based on theSession Initiation Protocol (SIP) which creates a common platform forenabling a broad range of advanced Internet-based multimedia servicesand applications on top of a packet switched network.

SIP provides an extensible event mechanism, enabling a specific serviceor SIP event package delivery, to route a set of state information orone or more notifications complying with a specific requested servicefrom a server to a subscribing client.

IMS presence is one example of a service and a SIP event package that auser can subscribe for in order to obtain information about anotherusers reach ability, availability and/or willingness of communication.The presence service can be used to indicate whether certain users areonline or not and if online, whether they are idle or busy. Presenceservice also allows users to share details of their communication meansand capabilities with other users.

One example of a general SIP-based presence architecture in the IMSaccording to the prior art is illustrated in FIG. 1.

A SIP/IMS network is a network of servers, performing a variety ofservices in support of the presence service, such as e.g. routing,authentication and compression. When the presence service is realizedusing IMS, the SIP/IMS network will perform a number of additionalfunctions in support of the presence service, such as, e.g. routing ofthe SIP signaling between the presence sources, Watchers and a PresenceServer (PS), authentication and authorization of the described entities,maintaining of the registration state and providing of charginginformation.

FIG. 1 shows a Watcher or a Watching client 100, requiring presenceinformation associated with another user. Watcher 100 may get access torequested presence information provided via SIP/IMS network 101 viaaccess network 102. The user of interest to the Watcher 100, istypically referred to as a Presentity 103. Presentity 103 may access theSIP/IMS network via the same access network as the Watcher 100, or as inthis case, via another access network 104.

Throughout this document, both the Watcher 100 and the Presentity 103will be defined as a combination of a user, or an automated functionoperating on behalf of a user, and a user agent (UA) located in an IMSterminal, such as e.g. a stationary PC, a laptop, a PDA or a cellulartelephone, and adapted to contribute to the execution of a number ofservices, each of which is identified by a SIP event package.

The IMS network consists of conventional IMS nodes, such as Proxy CallSession Control Functions 105, 106 (P-CSCF's), a P-CSCF being the firstpoint of contact between an IMS terminal and the SIP/IMS network,Serving Call Session Control Functions 107 (S-CSCF's), a S-CSCF beingused as the central node of the signaling plane, and Interrogating CallSession Control Functions 108 (I-CSCF's), providing SIP proxy serverfunctionality, as well as conventional databases, i.e. one or more HomeSubscriber Servers 109 (HSS), being the central repository foruser-related information, and, in case the network comprises more thanone HSS, a Subscriber Location Function 110 (SLF), responsible formapping user's addresses to an appropriate HSS.

In addition to the nodes mentioned above, the IMS network also typicallycomprises a plurality of Application Servers (AS's), which are SIPentities that hosts and executes different types of services toauthorized users. FIG. 1 comprises two AS's, namely a Presence Server111 (PS), which may be responsible for managing a presence service, anda Presence Source 112, which is an entity responsible for providingupdated presence information to authorized Watchers via the PS 111 onbehalf of a Presentity.

The network also comprises a Resource List Server 113 (RLS). An RLS is afunctional entity that accepts and manages subscriptions to presencelists, which enables a Watcher to subscribe to presence information ofmultiple entities using only one single subscription transaction,thereby saving not only bandwidth, but also reducing the powerconsumption of the Watchers UE's.

Although FIG. 1 only comprises one Presence Source, there are typicallya plurality of different Presence Sources available at an IMS network,each of which provides presence information of different categories toone or more Presence Server. It is also to be understood that a typicalIMS network may comprise additional CSCF nodes of the types alreadymentioned, as well as other types of nodes which have been omitted,since they are of no relevant importance to the understanding of theauthorization mechanism being the scope of this document.

Another example of a service type being of interest for the describedmechanism is the support of XML Configuration Access Protocol (XCAP)changes. XCAP is a generic protocol that can be used for a number ofpurposes related to the configuration of XML documents stored in aserver. This may include, e.g. updating of preferences, presence lists,privacy, or authorization policies.

Notifications, provided to a Watcher according to a requested SIP eventpackage, comprising e.g. presence information are not SIP trafficcontrol signaling. The same channel, i.e. the SIP control signalingchannel, is, however, used both for the transmission of notifications,and for the transmission of the SIP traffic control signaling.

Not only can a presence notification, an XCAP document, or any othertype of notification be quite large. This type of information can alsoarrive at any time, and, thus, notifications according to a SIP eventpackage may cause interference problems with the normal SIP trafficcontrol signaling.

In addition, since SIP traffic control signaling often has a higherpriority than a media connection, notifications may be exposed todelays, or, during unfavorable conditions, even interruptions.

SUMMARY

The object of the present invention is to address at least the problemsoutlined above. In particular, it is an object of the present inventionto provide a solution that can separate the transmission ofnotifications between an information source and a subscribing unit fromthe SIP control channel signaling so that notifications are deliveredvia the media plane, while the SIP control channel signaling istransmitted over the signaling plane.

According to one aspect, the present invention provides a method ofretrieving information delivered from a Notifying node of a SIP/IMSnetwork to a Watcher Client, as executed by the Watcher Client. TheWatcher Client establishes a connection with a Watcher Proxy which isadapted to handle SIP subscriptions, i.e. subscriptions for a specificservice which can be identified by a SIP event package. The WatcherClient uses the connection to initiate a SIP subscription between theWatching Proxy and the Notifying node. This can be executed byforwarding an embedded SIP subscribe message to the Watcher Proxy viathe established connection. The Watcher Client then awaits reception ofone or more notifications associated with the SIP subscription from theWatcher Proxy, wherein the notifications are delivered to the WatcherClient via the connection as an embedded SIP notify message.

The received notifications may be buffered at the Watcher Client, beforethey are handled according to predetermined rules.

According to one embodiment, the connection may be established by usinga SIP session, which has been set-up in an initial step.

According to another aspect, the present invention provides a method ofdelivering information from a Notifying node of a SIP/IMS network to aWatcher Client, as executed by a Watcher Proxy.

Initially, the Watcher Proxy establishes a connection with the WatcherClient, in response to a session request received from the WatcherClient. Via the established connection, the Watcher Client then receivesa request for a SIP subscription from the Watcher Client, wherein theSIP subscription is delivered via the connection as an embedded SIPsubscribe message. In response to receiving the request, the WatcherProxy sets-up a backend SIP subscription with the Notifying node. Fromnow on, the Watcher Proxy may receive one or more notificationsassociated with the SIP subscription from the Notifying node. Receivednotifications are then transmitted from the Watcher Proxy to the WatcherClient via the connection as embedded SIP notify messages.

The session request used for initiating the described connection may bea SIP invite.

The transmitting step may be executed according to predeterminedpriority policies, specified for said connection.

The described connection may be a TCP connection, which is establishedusing the SIP protocol.

The connection may also be configured as a Message Session RelayProtocol (MSRP) connection, wherein the embedded message will beembedded into an MSRP message.

According to further aspects, the present invention provides a client,which may be referred to e.g. as a Watcher Client and a node, which maybe referred to e.g. as a Watcher Proxy, adapted to execute the methoddescribed above.

Further features and benefits of the present invention will becomeapparent from the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by means ofexemplary embodiments and with reference to the accompanying drawings,in which:

FIG. 1 illustrates a general SIP based presence architecture in the IMS,according to the prior art.

FIG. 2 is a signaling diagram, illustrating a method of deliveringnotifications, according to one embodiment.

FIG. 3 is a flow chart illustrating the steps of a procedure executed bya Watcher Client for retrieving information from a Notifying node,according to one embodiment.

FIG. 4 is a flow chart illustrating the steps of a procedure executed bya Watcher Proxy for delivering information from a Notifying node to aWatcher Client, according to one embodiment.

FIG. 5 illustrates a Watcher Client, communicating with a Watcher Proxy,according to one embodiment.

FIG. 6 illustrates a Watcher Proxy, communicating with a Notifying nodeand a Watcher Proxy, according to one embodiment.

DETAILED DESCRIPTION

In order to handle at least some of the problems mentioned above,notifications according to a SIP event package, such as e.g. presenceinformation or changes in XCAP documents, will be handled as media whentransmitted between a Presentity and a Watcher, or a subscriber. Insteadof using a SIP control channel signaling connection for transmission ofnotifications delivered between an RLS/PS and a Watcher, a separatemedia connection will be set-up between the Watcher and a new logicalentity, referred to as a Watcher Proxy. Alternatively, the new entitymay be referred to as a Notification Proxy.

The media connection may be used for transmissions associated with anytype of SIP event packages, thereby separating this type oftransmissions from the ordinary SIP control channel signaling, i.e. theWatcher Proxy is not restricted to handling transmission associated onlywith the presence service.

One purpose with introducing a Watcher Proxy therefore is to gain bettercontrol over the SIP notification mechanism used over the SIP/IMSnetwork, without having to change the remaining network infrastructureor the mechanisms presently used for the SIP traffic control signalinghandling. The Watcher Proxy will provide a distinct separation betweennotification delivery and SIP traffic control signaling by enablingtunneling of one or more SIP subscriptions over one single session. Inother words, all SIP subscriptions to all services available via theSIP/IMS network may be executed via the Watcher Proxy, using one singlesession, separating content delivery from the SIP control signaling.

Throughout this document, we define a Watcher or a Watcher Client, as auser, having a User Equipment (UE), provided with a User Agent (UA)adapted to handle SIP subscriptions, such as e.g. subscriptions forpresence information of a specific Presentity. In the context describedin this documents, the Watcher could also be referred to as aSubscriber, and, thus, the Watcher Client could be referred to asSubscribing Client. Content associated with a respective SIPsubscription is provided from a Presentity or from an entity operatingon behalf of the Presentity, to a Notifying node, such as e.g. anApplication Server (AS) or a Presence Server (PS), as publications, i.e.as SIP publish messages.

Since the communication between the Presentity/content provider and theNotifying node is provided in a conventional manner, also when applyingthe suggested SIP event package delivery mechanism, this communicationwill not be discussed any further in this document. Delivery ofnotifications associated with a SIP event package therefore consequentlywill be described, starting at an AS and terminating at a subscribingWatcher Client.

The new Watcher Proxy will set-up a backend subscription, usingconventional SIP subscribe procedures towards a Notifying node in orderto be able to handle arriving notifications. As for the connectionbetween the Watcher Proxy and the Watcher, however, the Watcher Proxywill use a media connection, typically a TCP connection, such as e.g. aMessage Session Relay Protocol (MSRP) connection, which will beestablished using the SIP protocol. MSRP is a simple text-based protocolwhose messages are either requests or responses that are run on themedia plane. According to the suggested mechanism, the connection willbe used for transmission of SIP notifications, embedded into a message,i.e. an MSRP message.

A method adapted to provide information delivery from a Notifying nodeof a SIP/IMS network to a Watcher Client according to one embodimentwill now be described in further detail with reference to FIG. 2. Theexample illustrated in the figure comprises a Watcher Client 200,subscribing to a service, which is provided to the Watcher Client via aNotifying node 203.

Initially, Watcher Client 200 forwards a request, which in thisembodiment is a SIP invite, in order to be able to establish a TCPconnection, e.g. an MSRP connection, with a Watcher Proxy 202. TheWatcher Proxy 202 will be the end point for the SIP invite, and will beacting as a Business-to-business User Agent (B2BUA) towards theNotifying node 203. It is to be understood, that in a typical scenario,the Watcher Proxy 202 may be acting as a B2BUA towards a plurality ofNotifying nodes. As indicated with a first step 2:1, Watcher Client 200therefore forwards the SIP invite to a Call Session Control Function 201(CSCF) of a SIP/IMS network. Instead of forwarding the SIP invitedirectly to the Notifying node 203, as would have been standardprocedures for a typical SIP session, the SIP invite is forwarded fromthe SIP/IMS network to the Watcher Proxy 202 in another step 2:2. TheWatcher Proxy 202 may be implemented as a separate node or as a functionintegrated in another existing node, such as e.g. an RLS.

In a next step 2:3, the SIP session is used for establishing a TOPconnection, such as e.g. an MSRP connection, which will be used forinitiating a SIP subscription. The initiation of the SIP subscriptionwill be achieved by forwarding a SIP subscribe message to Watcher Proxy202 over the TCP connection, wherein the SIP subscribe message isembedded into another message, i.e. an MSRP message, if the TCPconnection is an MSRP connection. The SIP subscribe message, is arequest for a specific service, identified by a SIP event package, andprovided via the Notifying node 203.

In response to the SIP subscribe message, Watcher Proxy 202 will nowset-up a backend, or background subscription, towards the Serverproviding the requested service, i.e. Notifying Node 203. In the figure,this is indicated with a step 2:4, showing how the Watcher Proxy 202forwards the SIP subscribe to the CSCF 201. Notifying node 203 isidentified by CSCF, co-operating with other nodes of the SIP/IMSnetwork, in a conventional manner, and the required backend subscriptioncan be established by setting-up a connection also between CSCF 201 andthe Notifying node 203 in a next step 2:5. Consequently, there is now aSIP based backend subscription established between the Notifying node203 and the Watcher Proxy 202, and a TCP based connection establishedbetween the Watcher Proxy 202 and the Watcher 200.

Any notification, i.e. SIP notify, arriving to the Notifying node 203from a Presentity, or any other source operating on behalf of thePresentity, will now be forwarded to the client which created thebackend subscription, in this case Watcher Proxy 202, as indicated witha step 2:6.

When delivering a SIP notify to the Watcher Client 200, and possiblyalso to a plurality of additional Watcher Clients, Watcher Proxy 202,will use the channel, established in step 2:3. Step 2:3 resulted in anestablishment of a persistent connection between Watcher Client 200 andWatcher Proxy 202, which will be used whenever a notification, which isassociated with a SIP subscription for a specific service, identified bya SIP event package and set-up via the persistent connection, isreceived from the Notifying node 203. Every notification arriving to theWatching Proxy 202 will therefore be delivered to Watcher Client 200over the TCP based channel, embedded into a message, e.g. an MSRPmessage, as indicated with the final step 2:7, i.e. notificationsassociated with different SIP subscriptions will be tunneled over onesingle session.

In FIG. 3, a flow chart is shown of a procedure for retrievinginformation from a Notifying node according to one embodiment. Thisprocedure may basically correspond with the example shown in FIG. 2.

In a first step 300, a connection which will be able to separate thenotification traffic from the SIP traffic control signaling isestablished between a Watcher Client and a Watcher Proxy. This isinitiated with a SIP session, as indicated with steps 2:1 and 2:2 inFIG. 2.

In a next step 301, the established connection is used for initiating aSIP subscription with a Notifying node, as described above for step 2:3in FIG. 2, wherein a SIP subscribe will be delivered over theestablished connected embedded into a message.

Once the Watcher Proxy has set-up a connection, i.e. a backend SIPsubscription, with the Notifying node the Watcher Client may receivenotifications delivered via the connection, where the notifications areembedded into a message, as indicated with a final step 302, as well aswith step 2:7 of FIG. 2.

FIG. 4 shows another flow chart, illustrating the correspondingprocedure, executed at the Watcher Proxy, according to one embodiment.

In a first step 400 of FIG. 4, a connection is established with aWatcher Client, in response to a session request, typically aSIP-session request, received from the Watcher Client. Once theconnection has been set-up, the Watcher Proxy may receive a request fora SIP subscription from the Watcher Client via the connection, whereinthe SIP subscribe is embedded into a message. This is indicated withanother step 401.

In response to the SIP subscribe, the Watcher proxy establishes abackend SIP subscription with the notifying node, as indicated with astep 402 and steps 2:4 and 2:5 in FIG. 2.

Notifications delivered from the Notifying node to the Watcher Clientwill now be transmitted, first to the Watcher Proxy 202 via a SIPnotify, as indicated with another step 403 and step 2:6 in FIG. 2. Atthe Watcher Proxy, the notification, i.e. the SIP notify message, isthen embedded into another message and transmitted via the connectionwhich was established in step 400, and the embedded SIP notify istransmitted to the Watcher Client in a final step 404.

A Watcher Client which will be able to operate in accordance with themethod described above will require functionality adapted therefore. AWatcher Client according to one embodiment will therefore be describedwith reference to FIG. 5. A Watcher Client may be implemented in anykind of stationary or mobile User Equipment, such as, e.g. a desktopcomputer, a Laptop, a mobile telephone or a PDA.

According to FIG. 5, a Watcher client 500, comprises a communicationunit 501 for setting-up a SIP session 5:1, 5:2 with a Watcher Proxy 502,via a CSCF 503 of a SIP/IMS network, and for establishing anotherconnection 5:3 with the Watcher Proxy 502 using the SIP session 5:1,5:2.

The communication unit is also adapted to use connection 5:3 forinitiating a backend SIP subscription between Watcher 502 Proxy and aNotifying node 504 by embedding a SIP subscribe message and byforwarding the message to Watcher Proxy 502 via said other connection.The communication unit 501 is also adapted to receive notifications,i.e. SIP notify messages, associated with the requested SIP subscriptionfrom the Watcher Proxy 502 and delivered as embedded SIP notify messagesvia connection 5:3.

In order for a processing unit 505 of the Watcher client 500 to be ableto handle SIP notify messages, arriving over its own IP ports, thecommunication unit 501 of the Watcher Client 500, typically also will beprovided with a buffer 506, adapted for this purpose. Thereby, theWatcher Client 500 will be able to buffer SIP notify messages, until anyreal time media and SIP traffic has been handled accordingly. The buffer506 is typically adapted to buffer SIP notify messages according topredetermined rules.

A Watcher Proxy adapted to execute the method described above, accordingto one embodiment, will now be described in further detail withreference to FIG. 6.

The Watcher Proxy 600 of FIG. 6 is adapted to forward SIP notifymessages, provided from a Notifying client 601, to a Watcher client 602,via a connection 5:3, which has been set-up via a SIP session 3:1,3:2.The Watcher Proxy 600 comprises a first communication unit 603 forsetting-up the SIP session 5:1,5:2 with Watcher Client 602, via a CSCF604 of a SIP/IMS network, and for establishing connection 5:3 withWatcher Client 602.

Watcher Proxy 600 also comprises a second communication unit 605, whichis adapted to set-up a backend SIP subscription with the Notifying node601, to be used when forwarding a SIP notify message which has beenreceived from the Notifying node 601, to the Watcher Client 602 via thefirst communication unit 603 and connection 3:3, as an embedded SIPnotify message. The SIP notify message is embedded by a processing unit406 of the Watcher Proxy 400.

As mentioned above, the Watcher Proxy, as described in this document, isadapted to handle all types of SIP event packages. This means that aWatcher Client will be able to request for any type of service which isidentified by a specific SIP event package. In addition, the contentassociated with the respective service will be delivered via a channel,e.g. an MSRP channel, other than the one used for the SIP trafficcontrol signaling, and thus, SIP subscribe traffic and SIP controltraffic will be transmitted via separate channels.

As specific priority policies may be defined for such a media channel,established between the Watcher Client and the Watcher Proxy, signalingtransmitted on this channel will not interfere with the conventional SIPtraffic control signaling. In addition, since traffic communicated overthe described media channel will be running over its own IP ports, theWatcher Client may also be able to treat this traffic separately, e.g.by buffering incoming media traffic according to predetermined rules,which may then be handled accordingly first after any real time mediaand time critical SIP traffic has been handled.

By introducing and implementing the proposed Watcher Proxy, it will bepossible to avoid that SIP subscribe traffic interfere with SIP controltraffic, such as e.g. SIP invite messages. As the Watcher Proxy is usingan existing protocol for the communication with the Watcher Client,existing mechanisms for policy handling may also be used, enabling aless complex implementation.

While the invention has been described with reference to specificexemplary embodiments, the description is in general only intended toillustrate the inventive concept and should not be taken as limiting thescope of the invention. Although the concepts of IMS, MSRP and XCAP havebeen used when, describing the above embodiments, any other similarsuitable standards, protocols and network elements may basically be usedas described herein. The present invention is generally defined by thefollowing independent claims.

1. A method of retrieving information delivered from a Notifying node ofa SIP/IMS network to a Watcher Client, comprising the following steps,executed by the Watcher Client: setting-up a SIP session with a Watcherproxy establishing a connection with the Watcher Proxy, using said SIPsession, said Watcher Proxy for handling SIP subscriptions, wherein eachSIP subscription is a subscription for a specific service, said servicebeing identified by a SIP event package, initiating a SIP subscriptionbetween said Watching Proxy and said Notifying node, by forwarding a SIPsubscribe message to said Watcher Proxy via said connection, said SIPsubscribe message being embedded in a Message Session Relay Protocol(MSRP) message, and receiving at least one notification associated withsaid SIP subscription from said Watcher Proxy, said notification beingdelivered via said connection as a SIP notify message embedded in a MSRPmessage, for enabling notifications to be transmitted via the SIP/IMSnetwork separate from a SIP control channel of said network.
 2. Themethod according to claim 1, further comprising the step of: bufferingeach of said at least one received notification prior to handling saideach of said at least one received notification according topredetermined rules.
 3. A method of delivering information from aNotifying node of a SIP/IMS network to a Watcher Client, comprising thefollowing steps: establishing a connection with said Watcher Client, inresponse to a session request received from the Watcher Client,receiving a request for a SIP subscription from said Watcher Client,said SIP subscription, being delivered as a SIP subscribe messageembedded in a Message Session Relay Protocol (MSRP) message, via saidconnection, setting-up a backend SIP subscription with said Notifyingnode, in response to receiving said request, receiving at least onenotification associated with said SIP subscription from said Notifyingnode, and transmitting each received notification to said Watcher Clientvia said connection as a SIP notify message embedded in a MSRP message,for enabling notifications to be transmitted via the SIP/IMS networkseparate from a SIP control channel of said network, wherein said stepsare executed by an intermediate Watcher Proxy, said Watcher Proxy forhandling SIP subscriptions, each of which is a subscription for aspecific service, each service being identified by a SIP event package.4. The method according to claim 3, wherein said session request is aSIP invite.
 5. The method according to claim 3, wherein saidtransmitting step is executed according to predetermined prioritypolicies, specified for said connection.
 6. The method according toclaim 3, wherein said connection is a TCP connection which isestablished using the SIP protocol.
 7. The method according to claim 3,wherein said connection is a Message Session Relay Protocol (MSRP)connection.
 8. A client for retrieving information delivered from aNotifying node of a SIP/IMS network, said client comprising: acommunication hardware unit for setting-up a SIP session with a WatcherProxy, said Watcher Proxy for handling SIP subscriptions, wherein eachSIP subscription is a subscription for a specific service, said servicebeing identified by a SIP event package, and for establishing anotherconnection with the Watcher Proxy using said SIP session, saidcommunication hardware unit using said another connection for initiatinga backend SIP subscription between said Watcher Proxy and said Notifyingnode by embedding a SIP subscribe message in a Message Session RelayProtocol (MSRP) message and by forwarding said MSRP message to theWatcher Proxy via said another connection, said communication hardwareunit also for receiving at least one SIP notify associated with said SIPsubscription from said Watcher Proxy and for delivering said SIP notifyembedded in a Message Session Relay Protocol (MSRP) message via saidanother connection, enabling notifications to be transmitted via theSIP/IMS network separate from a SIP control channel of said network, anda processing unit for processing said SIP notifying message.
 9. Theclient according to claim 8, wherein said client is a Watcher client.10. The client according to claim 8, wherein said hardware unit furthercomprises: a buffer for buffering, prior to handling, each of said atleast one received SIP notification messages, said buffering procedurebeing executed according to predetermined rules.
 11. The clientaccording to claim 8, wherein said client is implemented in a stationaryor a mobile User equipment.
 12. The client according to claim 11,wherein said User equipment is one of a: Desktop computer, a Laptop, amobile telephone or a PDA.
 13. A node for delivering information from aNotifying node of a SIP/IMS network to a Watcher Client, said nodecomprising: a first communication hardware unit for setting up a SIPsession with the Watcher Client, and for establishing another connectionwith said Watcher Client using said SIP session, said firstcommunication hardware unit also for receiving a request for a SIPsubscription, said request being a SIP subscribe message which isdelivered via said another connection embedded in a Message SessionRelay Protocol (MSRP) message, a second communication hardware unit forsetting up a backend SIP subscription with the Notifying node, inresponse to receiving said embedded SIP subscribe message and forreceiving at least one SIP notify message associated with said SIPsubscription from the Notifying node via said backend SIP subscription,said second communication hardware unit also for transmitting eachreceived SIP notify message to said Watcher Client via said connectionembedded in a Message Session Relay Protocol (MSRP) message for enablingnotifications to be transmitted via the SIP/IMS network separate from aSIP control channel of said network, and a processing unit for embeddinga received SIP notify message into said MSRP message, and for forwardingsaid embedded message to the Watcher Client via said first communicationhardware unit and said another connection.
 14. The node according toclaim 13, wherein said node is a Watcher Proxy which is for handling SIPsubscriptions, each of which is a subscription for a specific service,being identified by a SIP event package.